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SECTION  1  -  SCOPE  AND  PURPOSE 


This  manual  describes  the  Simple  Mail  Transfer  Protocol 

(SMTP)  Remote  Driver  (RD)  for  the  protocol  test  system. 

Q  S*— ^ 

Section  2 ,  The  Protocol  Test  System,  summarizes  the 
testing  procedures  used  by  the  protocol  laboratory.  Section 
3,  ^"Remote  Driver  Functions , ‘^contains  guidelines  for 
developing  a  RD  for  SMTP  where  an  implementation  under  test 
(IUT)  resides.  In  addition,  Section  3  describes  the 
commands  this  RD  must  interpret  and  execute  to  be  capable  of 
SMTP  testing.  The  response  packets  the  RD  must  send  back  to 
the  Central  Driver  "yL CD4-  are  also  specified. 
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SECTION  2  -  THE  PROTOCOL  TEST  SYSTEM 

The  protocol  test  system  (PTS)  exercises  an  IUT  performing 
peer  protocol  exchanges  with  a  reference  implementation.  A 
driver  controls  each  peer  protocol  through  its  upper  level 
interface.  To  generate  reproducible  results,  a  script 
controls  each  driver. 


The  major  components  of  the  PTS  are: 

o  Central  Driver  (CD)  --  To  coordinate  and  monitor 
protocol  testing; 

o  Remote  Driver  (RD)  --  To  exercise  the  protocol  IUT 
and  provide  communication  links  with  the  CD; 

o  Laboratory  Slave  Driver  (LSD)  --  To  exercise  the 
Protocol  Reference  Implementation,  record  protocol 
data  units  exchanged  over  the  test  connections,  and 
provide  links  with  the  CD; 

o  Test  Scenario  Language  ( TSL )  —  To  enable  a  tester 
to  specify  standardized  scripts; 

o  Scenario  Language  Compiler  and  Libraries  --  To 
produce  code  for  automated  testing;  and 

o  Protocol  Reference  Implementation  --  To  define 
standard  functions  for  the  level  being  tested. 

The  CD,  which  coordinates  and  monitors  protocol  testing, 
combines  the  input  it  receives  from  the  LSD  and  the  RD  to 
determine  the  success  or  failure  of  each  test. 


The  RD  receives  protocol  command  codes  from  the  CD, 
translates  and  issues  protocol  commands  to  the  IUT,  and 
sends  back  protocol  responses  from  the  IUT  to  the  CD. 

Driver  commands  control  the  RD  process  itself  and  do  not 
affect  the  IUT's  state.  Protocol  commands  that  the  RD 
passes  to  the  IUT  as  SMTP  commands  have  specific  parameters 
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and  directly  affect  the  IUT's  state.  Figure  3-2  diagrams 
the  flow  of  commands  and  data  between  the  drivers  and  their 
peer  protocols.  Section  3  explains  in  detail  the  command 
codes  and  the  format  of  the  data. 
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SECTION  3  -  REMOTE  DRIVER  DESIGN  AND  PROTOCOL  TESTING 

The  following  subsections  describe  the  Remote  Driver  (RD)  design 
and  explain  how  all  drivers  interact  to  communicate  protocol 
commands  or  responses  in  lab  testing. 


3 . 1  THE  COMMAND  CHANNEL 

All  drivers  except  the  RD  reside  at  the  protocol  laboratory.  The 
RD  operates  as  a  background  process  using  a  transport  level 
connection,  which  links  the  RD  at  a  remote  site  with  the  Central 
(CD),  the  laboratory  drivers,  and  the  reference  and  IUT 
protocols.  The  transport  protocol  in  use  is  the  Transport 
Control  Protocol  (TCP). 

To  set  up  the  command  channel,  the  RD  issues  a  passive  open  on  a 
well-known  port  and  waits  for  the  Central  Driver  (CD)  to  perform 
an  active  open  to  that  port.  The  RD  functions  as  server  and 
listens  for  further  connection  requests  from  the  CD  on  the  well- 
known  port  after  the  command  channel  has  been  established.  The 
command  channel  is  ready  when  the  transport  connection  to  the  RD 
and  slave  drivers  has  been  established,  and  all  drivers  have 
initiated  communications  with  their  respective  protocols. 

Figure  3-1  is  a  diagram  of  connection  establishment,  and  Table 
3-1  (p.  3-3)  gives  destinations  and  port  numbers.  Appendix  C 
includes  an  example  of  command  channel  establishment  implemented 
in  UNIX/C  (Figure  C-l). 
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( 


Central 

Driver 


( 

( 

( 


) 

DDN  ) 

_  > 

I 


Remote 

Driver 


Protocol 

IUT 


Transport  Connection 


Network 


Transport  Connection 


(background  process) 


Interprocess 
Commun ica  t ion 


Connection  Establishment 


3-3 


Table  3-1.  Destinations  and  Port  Numbers 


Destination 

Port  Number 

RD  Passive  Open  Port 

1040 

SMTP  IUT  Receiver  Passive 

25 

Open  Port 

3 . 2  FLOW  OF  COMMANDS 

Packets  containing  protocol  or  driver  command  codes  are  passed 
over  the  command  channel  from  the  CD  to  the  RD  (Figure  3-2,  p.  3- 
4;  Table  3-3,  p.  3-11).  The  RD  translates  these  codes  into  the 
appropriate  commands,  then  issues  the  commands  to  the  protocol 
IUT.  Similarly,  responses  from  the  protocol  IUT  are  received  by 
the  RD  and  forwarded  over  the  command  channel  to  the  CD  (Figure 
3-3,  p.  3-5).  The  CD  determines  from  the  combined  test  responses 
whether  the  IUT  has  functioned  as  expected  and  reacts 
accordingly,  by  taking  the  next  appropriate  action  in  the  testing 
process.  The  flow  of  commands  is  then  repeated. 


3.3  INPUTS  AND  OUTPUTS 

Data  are  transmitted  from  the  testing  facility  to  the  protocol 
laboratory  in  packets.  The  laboratory  implementation  of  the  RD 
uses  a  Packet  Assembler/Disassembler  (PAD)  function  to  control 
the  input  and  output  of  these  packets. 

The  RD  must  be  able  to  receive  packets  from  the  CD,  translate 
number  codes  into  commands,  and  interpret  ASCII  strings  of 
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Figure  3-2.  Flow  of  Commands  Between  the  Four  Types  of  Drivers 
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characters.  The  RD  must  also  be  able  to  send  one  of  three 
packets:  an  ACK  (Positive  Acknowledgment),  a  NAK  (Negative 

Acknowledgment),  or  a  data  packet  containing  either  protocol 
responses  or  driver  command  results.  The  RD  is  required  to 
acknowledge  the  receipt  of  every  driver  or  protocol  command. 
When  the  RD  is  able  to  read  and  interpret  a  packet  from  the  CD, 
it  responds  by  sending  an  ACK  packet.  If  it  is  unable  to  read 
the  packet,  the  RD  responds  by  sending  a  NAK  packet. 

All  codes  are  explained  in  detail  in  the  following  sections. 
Figure  3-5  (p.  3-7)  shows  the  structure  of  the  packets  on  the 
command  channel;  Figure  C-2  in  Appendix  C  defines  a  packet  in  C 
syntax.  The  packet  and  each  of  its  fields  are  ordered  in 
Internet  Protocol  (IP)  byte  order. 


3.3.1  The  Control  Flag  Field 

The  control  flag,  which  is  a  single  octet,  indicates  by  bit 
position  how  the  RD  should  interpret  the  rest  of  the  data  packet 
The  bit  positions  are  in  ascending  order  from  right  to  left,  as 
in  a  Digital  Equipment  Corporation  (DEC)  VAX.  Figure  3-4 
diagrams  the  bit-ordering  scheme. 

Control  Flag: 

< -  1  byte - > 


76543210 


bit  positions 


Figure  3-4.  The  Bit  Order  of  a  Byte 
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Figure  3-5.  Structure  of  the  Data  Packet  on  the  Command  Channel 


Table  3-2  summarizes  the  configuration  of  bit  positions  in  the 
control  flag.  Only  bit  positions  0,  1,  and  2  are  used.  The  RD 
sets  the  bit  in  position  0  to  one  (1)  to  indicate  that  an  ACK 
packet  is  being  sent.  If  the  RD  sets  the  bit  in  position  0  to 
zero  (0),  the  packet  being  transmitted  is  a  NAK.  Finally,  the  RD 
signals  the  transmission  of  a  data  packet  by  setting  the  bit  in 
position  1  to  one  (1).  Setting  the  data  bit  in  a  packet  could 
signal  either  that  the  RD  is  sending  a  protocol  response,  or  that 
it  is  sending  the  results  of  one  of  its  own  driver  operations. 

The  bit  in  position  2  of  the  first  octet  of  each  data  packet  sent 
by  the  CD  determines  whether  the  packet  contains  a  protocol  or  a 
driver  command. 


Table  3-2.  Bit  Positions  in  the  Control  Flag 


3.3.2  The  Error  Flag  Field 


Error  flags  will  explain  the  nature  of  an  error  occurring  at  the 
RD.  Because  error  codes  are  not  yet  implemented,  the  protocol 
test  system  makes  no  attempt  to  interpret  this  field. 
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3.3.3  The  Primitive  Code  Field 

The  primitive  code  field  can  be  interpreted  in  one  of  two  ways: 
either  as  a  protocol  primitive  code  or  as  a  driver  primitive 
code.  A  primitive  in  this  sense  means  a  command  that  describes 
some  action  within  the  protocol  or  the  driver. 


3. 3. 3.1  The  Protocol  Primitive  Codes 

If  the  control  flag  indicates  a  protocol  command  --  i.e.,  the  bit 
in  position  2  is  set  to  one  (1)  --  then  the  RD  must  translate  the 
integer  in  the  code  field  to  its  corresponding  protocol  primitive 
according  to  the  descriptions  and  the  code  numbers  in  Table  3-3. 
The  format  of  the  data  sent  by  the  RD  to  the  protocol  IUT  depends 
on  the  IUT's  Sender  interface,  but  the  RD  must  include  this 
translation  capability  in  its  function.  To  pass  qualification 
testing,  an  SMTP  IUT  must  be  able  to  perform  all  the  primitive 
actions  described  in  Table  3-3. 

The  RD  determines  whether  arguments  are  associated  with  a 
primitive  according  to  its  protocol  IUT.  If  arguments  are 
required  for  a  given  primitive,  they  will  be  supplied  in  the  data 
field  of  the  data  packet.  If  required  arguments  are  not 
supplied,  then  an  error  condition  occurs  and  the  RD  must  NAK  that 
packet . 

The  RD  can  determine  whether  the  required  arguments  are  present 
by  reading  the  num_bytes  field,  which  tells  how  many  bytes  of 
ASCII  data  are  in  the  data  field.  If  this  field  contains  a 
zero,  then  the  RD  assumes  no  arguments  have  been  supplied. 
However,  if  the  num_bytes  field  contains  any  positive  integer 
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from  0  to  4096,  the  RD  must  read  the  contents  of  the  data  field 
and  interpret  these  contents  as  the  primitive's  arguments.  An 
integer  outside  the  range  of  0  to  4096  means  the  packet  is  in 
error,  and  that  a  NAK  packet  should  be  returned. 

In  Table  3-3  the  primitive  commands  and  number  codes  are  followed 
by  one  or  more  argument  fields.  Arguments  are  located  in  the 
data  field  of  the  command  packet,  beginning  at  location  zero  and 

separated  by  ASCII  spaces.  Three  hyphens  (  -  )  in  the  table's 

argument  column  indicate  that  none  exist.  Arguments  within 
square  brackets  are  optional  (e.g.,  [ sendername ] ) . 


rcpt  (3)  forward_path 


data  (4) 


rset  (5) 
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itive  Commands,  Number  Codes,  and 
;quent  SMTP  IUT  Actions  (p.  1  of  3) 


SMTP  IUT  Action 


Same  as  MIL-STD-1781 •  Causes  the 
Sender  SMTP  to  send  the  HELO  command 
over  the  command  connection.  The 
optional  argument  field  is  the 
Sender's  identity. 

Same  as  MIL-STD-1781.  Causes  the 
Sender  SMTP  to  send  the  MAIL  command 
over  the  command  connection.  The 
argument  field  identifies  the 
Sender's  reversepath .  Initiates  a 
mail  transaction  in  which  the  mail 
data  are  delivered  to  one  or  more 
mailboxes . 

Same  as  MIL-STD-1781.  Causes  the 
Sender  SMTP  to  send  the  RCPT  command 
over  the  command  connection.  The 
argument  field  identifies  the 
forward_path  to  the  destination 
ma i lbox . 

Same  as  MIL-STD-1781.  Causes  the 
Sender  SMTP  to  send  the  DATA  command 
over  the  command  connection.  Causes 
the  Receiver  SMTP  to  enter  the  state 
of  accepting  message  data. 

Same  as  MIL-STD-1781.  The  current 
mail  transaction  is  aborted.  Any 
stored  sender,  recipient,  and  mail 
data  must  be  discarded;  and  all 
buffers  and  state  tables  are 
cleared. 
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(Table  3-3,  p.  2  of  3) 


1 

|  Primitive 

- 1 

! 

|  ( No .  Code ) 

J _ 

Argument 

I 

SMTP  IUT  Action 

send  (6) 


soml  (7) 


saml  (8) 


vrfy  (9) 


(  rever se_path !  Same  as  MrL-STD-1781 .  Causes  the 
Sender  SMTP  to  issue  the  SEND 
command  over  the  command  connection. 
The  argument  field  identifies  the 
Sender's  reverse_path .  Initiates  a 
mail  transaction  in  which  the  mail 
data  are  delivered  to  one  or  more 
terminals . 


[  reverse_path ]  Same  as  MIL-STD-1781 .  Causes  the 
Sender  SMTP  to  issue  the  SOML 
command  over  the  command  connection. 
The  argument  field  identifies  the 
Sender's  reversepath .  Initiates  a 
mail  transaction  in  which  the  mail 
data  are  delivered  to  one  or  more 
terminals  or  mailboxes. 

( reverse_path I  Same  as  MIL-STD-1781.  Causes  the 
Sender  SMTP  to  issue  the  SAML 
command  over  the  command  connection. 
The  argument  field  identifies  the 
Sender's  reverse_path .  Initiates  a 
mail  transaction  in  which  the  mail 
data  are  delivered  to  one  or  more 
terminals  and  mailboxes. 


username  Same  as  MIL-STD-1781.  Causes  the 

Sender  SMTP  to  send  the  VRFY  command 
over  the  command  connection.  The 
Receiver  confirms  that  the  argument 
indicates  a  valid  username.  If 
valid,  the  complete  name  of 
the  user  (if  known)  and  the  fully 
specified  mailbox  are  returned. 
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(Table  3-3,  p.  3  of  3) 


Primitive  |  | 

(No.  Code)  !  Argument  ]  SMTP  IUT  Action 


expn  (10)  mailing_list  Same  as  MIL-STD-1781 .  Causes  the 

Sender  SMTP  to  send  the  EXPN  command 
over  the  command  connection.  The 
Receiver  confirms  that  the  argument 
indicates  a  valid  mailinglist .  If 
the  mailing  list  is  valid,  the  full 
membership  of  that  list  (if  known) 
is  returned  in  a  multiline  reply  as 
user  names  and  fully  specified 
ma i lboxes . 

help  (11)  [cmd_string|  Causes  the  Sender  SMTP  to  send  the 

HELP  command  over  the  command 
connection.  This  command  causes  the 
Receiver  to  send  helpful  information 
regarding  its  implementation  over 
the  command  connection  to  the 
Sender.  The  command  may  take  an 
argument  (e.g.,  any  command  name) 
and  return  more  specific  information 
as  a  response. 

noop  (12)  -  Same  as  MIL-STD-1781.  Causes  the 

Sender  SMTP  to  send  the  NOOP  command 
over  the  command  connection.  This 
command  does  not  affect  any  para¬ 
meters  or  previously  entered 
commands.  It  specifies  no  action, 
but  the  Receiver  must  send  an  OK 
reply . 

quit  (13)  -  Same  as  MIL-STD-1781.  Causes  the 

Sender  SMTP  to  send  the  QUIT  command 
over  the  command  connection.  The 
Receiver  must  send  an  OK  reply,  then 
close  the  transmission  channel. 

turn  (14)  -  Same  as  MIL-STD-1781.  Causes  the 

Sender  SMTP  to  send  the  TURN  command 
over  the  command  connection. 

This  command  causes  the  Sender  and 
Receiver  SMTP  to  switch  roles  if  the 
Receiver  agrees. 
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3. 3. 3-2  The  Driver  Primitive  Codes 

If  the  control  flag  indicates  a  driver  command  (the  bit  in 
position  2  is  set  to  zero),  the  RD  must  translate  the  integer 
contained  in  the  code  field  to  its  corresponding  driver  primitive 
(Table  3-4).  The  RD  then  performs  the  appropriate  action,  as 
specified  in  the  following  sections. 

In  Table  3-4,  the  primitive  commands  and  number  codes  are 
followed  by  one  or  more  argument  fields.  Arguments  are  located 
in  the  data  field  of  the  command  packet,  beginning  at  location 

zero  and  separated  by  ASCII  spaces.  Three  hyphens  (  -  )  in  the 

table's  argument  column  indicate  that  none  exist.  Arguments 
inside  square  brackets  (  (  1  )  are  optional.  If  arguments  are 
within  braces  and  separated  by  vertical  bars,  then  one  of  the 
arguments  is  mandatory  (e.g.,  {  forward_path  I  mailing_list  }). 


3. 3. 3. 2.1  The  DIE  Driver  Primitive 

If  the  RD  receives  a  driver  primitive  code  of  31,  indicating  the 
DIE  command,  after  ACKing  the  driver  primitive  packet,  the  RD 
must  close  the  test  connection  to  the  CD,  close  all  connections 
to  the  IUT,  and  halt  the  RD  process.  This  command  does  not  send 
any  data  across  the  test  connection  after  the  initial  ACK  packet 


3. 3. 3. 2. 2  The  CLOSE  Driver  Primitive 

If  the  RD  receives  a  driver  primitive  code  of  32,  indicating  the 
CLOSE  command,  after  ACKing  the  driver  primitive  packet,  the  RD 
must  close  the  test  connection  to  the  CD,  close  all  connections 
to  the  IUT  (RD-to-IUT  connections  are  implementation  dependent). 
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and  wait  for  a  new  connection  attempt  from  the  CD.  The  RD 
process  does  not  die  as  in  the  DIE  command;  it  waits  for  a  new 
connection.  This  command  does  not  send  any  data  across  the  test 
connection  after  the  initial  ACK  packet. 
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Table  3-4.  The  Driver  Primitive  Commands,  Number  Codes,  and 
Arguments,  with  Consequent  Remote  Driver  Actions  (p.  1  of  2) 


;  Driver  |  ! 

j  Primitive  |  I 

j  (No.  Code)  |  Argument  |  Remote  Driver  Action 


die  (31)  -  Causes  the  RD  to  close  the  test 

connection  to  the  CD,  close  all 
connections  to  the  IUT,  and  die. 
This  command  does  not  send  any  data 
across  the  command  connection. 
(Section  3. 3. 3. 2.1  gives  a  detailed 
description . ) 

close  (32)  -  Causes  the  RD  to  close  the  test 

connection  to  the  CD,  close  all 
connections  to  the  IUT,  and  wait 
for  a  new  connection  to  the  CD. 

This  command  does  not  send  any  data 
across  the  command  connection. 
(Section  3. 3. 3. 2. 2  gives  a  detailed 
descr  ipt ion . ) 

spool  (41)  username  Causes  the  RD  to  send  all  the 

received  mail  messages  for  the 
specified  user  over  the  command 
channel  to  the  CD.  If  the  RD  is 
unable  to  spool  the  mailbox,  it 
sends  the  message  "! (ERROR!!" 
to  the  CD.  The  end  of  the  mail 
message  is  indicated  by  the  string 
” END_OF_SPOOL" .  (Section  3. 3. 3. 2. 3 
gives  details. ) 

delete  (42)  username  Causes  the  RD  to  delete  all  the 

received  mail  messages  for  the 
specified  user  from  the  user's 
mailbox.  If  the  RD  is  unable  to 
delete  the  mailbox,  it  sends  the 
message  " ! ! ERROR ! ! "  to  the  CD. 
(Section  3. 3. 3. 2. 4  gives  details.) 
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(Table  3-4,  p.2  of  2) 


! Driver ] ; 
j  Primitive  |  ! 

(No.  Code)  |  Argument  |  Remote  Driver  Action 


queue  (43)  delivery  username 

{  forward_path  !  mailing_list  }  [message] 

Causes  the  RD  to  send  message  from 
specified  username  to 
forward_path ;  or  list  of 
forward  paths  represented  by 
mailing_list.  The  delivery 
parameter  indicates  one  of  the  SMTP 
methods  of  mail  delivery  (MAIL, 
SEND,  SAML ,  or  SOML ) .  If  the 
message  field  is  not  present,  the 
contents  of  the  specified  user's 
mailbox  are  sent  to  forwardpath . 

If  the  RD  is  unable  to  queue  the 
message  or  the  mailbox,  it  replies 
" ! ! ERROR ! ! "  to  the  CD.  The  end  of 
the  mail  message  is  indicated  by 
the  string  "END_OF_SPOOL" .  (See 
Section  3. 3. 3. 2. 5  for  a  detailed 
descr  lpt  ion .  1 
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3. 3. 3. 2. 3  The  SPOOL  Driver  Primitive 

If  the  RD  receives  a  driver  primitive  code  of  41,  indicating  the 
SPOOL  command,  after  ACKing  the  driver  primitive  packet,  the  RD 
must  send  all  the  received  mail  messages  for  the  specified  user 
over  the  test  connection  to  the  CD.  When  the  RD  has  finished 
sending  all  the  mail  data  (in  data  packets),  it  generates  a 
string  "END_OF_SPOOL"  to  indicate  end  of  data.  The  string  is 
sent  as  7-bit  ASCII  characters.  The  underbar  character  (  ) 

is  octal  ASCII  character  137.  If  the  RD  cannot  send  the  mail 
data  for  any  reason,  after  ACKing  the  command,  it  must  send  the 
string  "! (ERROR!!"  in  a  data  packet  to  the  CD.  The  CD  performs  a 
string  search  on  the  data  it  receives  and  determines  the  success 
or  failure  of  a  test  according  to  the  results  of  the  search,  so 
care  should  be  taken  to  return  the  data  accurately. 

Example : 

spool  "testl" 


3. 3. 3. 2. 4  The  DELETE  Driver  Primitive 

If  the  RD  receives  a  driver  primitive  code  of  42,  indicating  the 
DELETE  command,  after  ACKing  the  driver  primitive  packet,  the  RD 
must  delete  all  the  received  mail  messages  for  the  specified  user 
from  the  user's  mailbox. 

Example : 

delete  "testl" 
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3. 3. 3. 2. 5  The  QUEUE  Driver  Primitive 

If  the  RD  receives  a  driver  primitive  code  of  43,  indicating  the 
QUEUE  command,  after  ACKing  the  driver  primitive  packet,  the  RD 
must  cause  the  IUT  to  deliver  the  message  from  the  user  specified 
by  the  username  parameter  to  the  forward_path  or  to  the  list  of 
forward_paths  represented  by  ma i 1 ing_l ist .  The  method  of 
delivery  is  specified  by  the  delivery  parameter.  If  the  message 
field  is  not  present,  then  the  contents  of  the  user's  mailbox  is 
sent  to  the  f orward_path .  If  the  RD  is  unable  to  delete  the  mail 
data  for  any  reason,  after  ACKing  the  command,  it  must  send  the 
string  "!  .'ERROR!!"  in  a  data  packet  to  the  CD.  The  CD  performs  a 
string  search  on  the  data  it  receives  and  determines  the  success 

or  failure  of  a  test  according  to  the  results  of  the  search,  so 

care  should  be  taken  to  send  back  the  data  accurately.  The 

fields  are  explained  in  detail  in  the  following  paragraphs. 

The  delivery  field  indicates  which  SMTP  method  of  delivery  will 
be  used  for  message  transmission.  There  are  only  four 
possibilities:  MAIL,  SEND,  SAML ,  or  SOML. 

The  second  field  is  the  username  field,  which  is  a  character 
string  containing  a  valid  source  mailbox. 

The  third  field  contains  either  a  forward_path  or  a  mailing_list. 
A  forward_path  describes  a  destination  mailbox  and  how  to  get 
there.  The  syntax  of  the  forward_path  must  follow  MIL-STD-1781 . 
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A  mailing  list  is  a  list  of  forward  paths.  It  is  assumed  that 
"mailing_list"  is  a  local  list  at  the  IUT-host  and  that  the 
delivery  of  the  mail  messages  will  be  performed  by  multiple  RCPT 
commands . 

The  fourth  field  is  the  optional  message  field.  If  no  message  is 
specified,  the  contents  of  the  source  mailbox  specified  in  the 
username  field  will  be  used  as  the  mail  message.  If  the  message 
is  specified,  the  contents  of  the  string  --  contained  within 
double  quotes  —  will  be  used  as  the  contents  of  the  mail 
message . 

The  following  examples  of  some  possible  uses  of  the  QUEUE  driver 
primitive  may  help  explain  its  function.  These  examples  are 
excerpts  taken  from  a  typical  test  script.  (Test  scripts  define 
different  scenarios.)  The  RD  would  receive  the  number  code  for 
the  QUEUE  driver  primitive  (43),  and  translate  the  number  into 
the  appropriate  QUEUE  command  function  using  the  corresponding 
parameters  supplied  with  the  driver  primitive. 

Examples : 

queue  "MAIL  testl  < test2@protolabb>  Test_message_goes_here" 

This  command  transmits  a  mail  message  from  < testl@iUT-host>  to 
< test2@protolabb> ;  "IUT-host"  is  the  hostname  where  the  IUT 
resides.  The  message  is  the  string  "Test_message_goes_here" ;  and 
delivery  of  the  message  is  via  the  SMTP  MAIL  command. 
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queue  "SAML  testl  < test3@protolabb>  testing_123" 

This  command  transmits  a  message  from  <testl@IUT-host>  to 
<test3@protolabb> .  The  mail  message  data  consist  of  the  string 
"testing_123" ;  delivery  is  via  the  SMTP  SAML  command. 

queue  "SEND  testl  < test2@protolabb>" 

This  command  transmits  a  message  from  <. test2@protolabb>  to  the 
terminal  at  forward_path  < test2@protolabb> ,  if  the  user  "test2" 
is  logged  on  at  the  time.  The  SMTP  SEND  command  is  specified  as 
the  method  of  delivery,  so  the  message  must  be  delivered  to  the 
destination  terminal.  Since  no  message  parameter  is  specified, 
the  message  consists  of  the  contents  of  the  mailbox  of  the  user 
"testl" . 

queue  "SAML  testl  testlist  testing_123" 

This  command  transmits  a  mail  message  from  < testl@IUT-host>  to 
the  members  of  the  mailing  list  "testlist".  It  is  assumed  that 
"testlist"  is  a  local  list  at  the  IUT-host  and  that  the  delivery 
of  the  mail  messages,  via  the  SAML  command,  will  be  performed  by 
multiple  RCPT  commands.  The  mail  message  data  consist  of  the 
string  "testing_123" . 


3 . 4  ACK/NAK  PACKETS 

The  RD  is  required  to  acknowledge  the  receipt  of  every  driver  or 
protocol  command  (ACK  =  positive  acknowledgment;  NAK  =  negative 
acknowledgment).  When  it  is  able  to  read  and  interpret  a  packet 
from  the  TCP  connection,  the  RD  sends  an  ACK  packet.  If  it 
detects  an  error,  however,  the  RD  responds  with  a  NAK  packet. 

The  RD  also  sends  a  NAK  packet  if  a  read  is  successful  but  a  code 
is  unknown;  or  if  some  other  field  is  in  error. 
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The  following  values  indicate  ACK  or  NAK  packets: 

ACK 


code  :  0 


cntl_flag  :  bit  position  0  set  to  one  (1) 
bit  position  1  is  unused 

bit  position  2  set  to  one  (1)  if  protocol 
command,  to  zero  (0)  if  driver  command 


num_bytes  :  0 


data  :  empty 


NAK 


code  :  0 


cntl_flag  :  bit  position  0  set  to  zero  (0) 
bit  position  1  is  unused 

bit  position  2  set  to  one  (1)  if  protocol 
command,  to  zero  (0)  if  driver  command 


num_bytes  :  0 


data 


empty 
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3.5  TIMING 

An  RD  has  no  intrinsic  timing  constraints,  but  i 
considerably  to  a  protocol  IUT's  response  time, 
the  CD  does  not  receive  a  data  packet  within  the 
in  a  script,  then  a  timeout  condition  will  occur 
condition  could  cause  an  IUT  to  fail  the  test. 


3.6  FLEXIBILITY 


should  not  add 
For  example,  if 
time  specified 
Such  a 


Although  RDs  have  no  special  flexibility  requirements,  adaptable 
hardware  and  software  enhance  their  operation  and  expandability. 
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APPENDIX  B  -  Glossary 

ACK  (Acknowledgment) 

In  data  transfer  between  devices,  data  are  blocked  into 
units  of  a  size  given  in  each  block's  header.  If  the 

received  data  are  found  to  be  without  errors,  the  receiving 
device  sends  an  ACK  block  back  to  the  transmitting  unit  to 
acknowledge  receipt.  The  transmitting  device  then  sends  the 
next  block.  If  the  receiving  unit  detects  errors  it  sends  a 
NAK  block  to  indicate  the  received  data  contained  errors. 

ASCII  (American  Standard  Code  for  Information  Interchange) 

A  standard  code  for  the  representation  of  alphanumeric 
information.  ASCII  is  an  8-bit  code  in  which  7  bits 
indicate  the  character  represented  and  the  8th,  high-order 
bit  is  used  for  parity. 

CD  (Central  Driver) 

DDN  (Defense  Data  Network) 

A  Department  of  Defense  packet-switched  network. 

DEC  (Digital  Equipment  Corporation) 

DoD  (Department  of  Defense) 


EDN  (Exploratory  Data  Network) 
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IUT  (Implementation  Under  Test) 

A  given  vendor's  protocol  implementation  and  the 
subject  of  the  immediate  test. 

MIL-STD  (Military  Standard) 

Specification  published  by  the  DoD. 

NAK  (Negative  Acknowledgment) 

In  data  transfer  between  devices,  a  NAK  block  is 
returned  by  the  receiving  device  to  the  sending  device  to 
indicate  the  preceding  data  block  contained  errors.  See 
also  ACK . 

packet  switching 

A  method  of  transmitting  messages  through  a  network  in 
which  long  messages  are  subdivided  into  short  packets.  The 
packets  are  then  transmitted  as  in  message  switching. 

PAD  (Packet  Assembler/Disassembler) 

In  this  document,  PAD  refers  to  a  module  of  a 
structured  program  responsible  for  reading  and  writing  data 
packets.  Not  to  be  confused  with  the  other  known  usage, 
which  describes  a  device  to  provide  service  to  asynchronous 
terminals  within  an  X.25  network. 

PAR  (Positive  Acknowledgment  and  Response) 

A  simple  communication  protocol  stating  that  every 
packet  received  must  be  either  ACKed  or  NAKed . 

protocol 

A  set  of  rules  governing  the  operation  of  functional 
units  to  achieve  communication. 
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TCP  (Transmission  Control  Protocol) 

The  DoD  standard  connection-oriented  transport  protocol 
used  to  provide  reliable,  sequenced,  end-to-end  service. 

ULP  (Upper  Level  Protocol) 

Any  protocol  above  TCP  in  the  layered  protocol 
hierarchy  that  uses  TCP.  This  term  includes  presentation 
layer  protocols,  session  layer  protocols,  and  user 
applications  such  as  the  protocol  test  system's  drivers. 
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APPENDIX  C  -  Examples  of  Remote  Driver  Implementation  in 

UNIX/C 

C.l  CONNECTION  ESTABLISHMENT 

The  protocol  laboratory  runs  in  a  UNIX  4.2  BSD  environment. 
The  lab's  example  RD  is  implemented  in  the  C  language,  which 
provides  access  to  several  interprocess  communication  system 
calls  (e.g.,  the  fork,  socket,  bind,  listen,  and  accept 
system  calls )  . 

The  design  of  the  RD  uses  the  Internet  Server  model.  The 
first  step  taken  by  the  RD  is  to  disassociate  itself  from 
the  controlling  terminal  of  the  invoker.  It  then  does  a 
passive  open  and  listens  at  the  published  well-known  port 
for  a  connection  request  from  the  Surrogate  Driver.  Using 
the  fork  system  call,  the  RD  creates  a  copy  of  itself  (a 
child  process),  so  that  it  can  continue  to  listen  for 
connection  requests  following  a  successful  connection.  It 
is  this  child  process  that  carries  out  the  functions  of  the 
RD,  communicating  over  the  established  command  channel.  The 
original,  or  parent,  process  remains  in  execution  and 
listens  to  the  well-known  port.  Figure  C-l  outlines  the 
establishment  of  the  command  channel  in  4.2  BSD  UNIX/C.  In 
addition  to  the  UNIX  system  calls,  the  example  uses  4.2  BSD 
library  calls  to  eliminate  direct  handling  of  Internet 
protocol  numbers  and  addressing. 

C . 2  A  PAD  FUNCTION 

A  Packet  Assembler/Disassembler  (PAD)  function  is  useful  for 
implementing  an  RD.  Because  the  two  basic  functions  of 
receiving  and  transmitting  packets  are  performed  repeatedly, 
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/*  COMMAND  CHANNEL  ESTABLISHMENT 

V 

struct  protoent  *pp; 

struct  servent  *sp; 

int  socket_number ,  socket_number 2 ; 

pp  =  getprotobyname( "tcp" )  /*  4.2  BSD  library  call  */ 

sp  =  getservbyname ( "remote_driver” ,  "tcp");*/  4.2  BSD 
library  call 
*/ 

#ifndef  DEBUG 
/* 

<<  disassociate  RD  from  controlling  terminal  here>> 

*/ 

#endif 


sin.sin_port  =  sp->s_port;  *  set  port  number  */ 


socket_number  =  socket ( AF_INET,  SOCK_STREAM ,  pp->p_proto) ; 
bind ( socket_number ,  ( caddr_t ) &sin ,  sizeof(sin),  0); 

1 isten ( socket_number ,  5);/*  passive  open  to  listen  at 

well-known  port 
★  / 

/ 

f or ( ; ; )  {  /*  do  forever  */ 

socket_number 2  =  accept ( socket_number ,  0,  0); 

if  (fork()  ==  0)  {  /*  this  is  the  child  process  if 

true  */  closelsocket  number); 

/*  socket_number 2  is  the  local 
connection 

*  name  of  the  command  channel 
*/ 

do_remote_dr iver_f unct ions ( socket_number 2 ) ; 

} 


} 


close(socket_number2 ) ;/ 
listening  */ 


/* 


*  the  parent  goes  back  to 
on  socket  number 


V 


Figure  C-l.  Outline  of  Connection  Establishment  in  4.2  BSD 

UNIX/C 
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it  may  be  wise  to  modularize  them.  When  the  RD  reads  data 
from  the  command  channel,  it  must  be  able  to  interpret  the 
bytes  correctly.  In  a  UNIX/C  implementation,  the  method 
used  to  achieve  this  result  is  to  load  the  data  into  a  data 
structure  where  distinct  fields  can  be  declared.  In  C,  this 
is  the  struct  declaration.  Each  collection  of  fields  can  be 
declared  and  referenced  as  a  whole.  The  term  packet  has 
been  used  in  this  document  as  the  name  of  this  data 
structure  reference.  The  struct  declaration  is  shown  in 
Figure  C-2. 


#def ine  MAX_TEXT_LEN  4096 

struct  remote_pack  { 

char  cntl_flag; 

char  err_flag; 

int  code; 

int  num_bytes; 

int  reserved; 

char  text [MAX  TEXT  LEN] ; 

} ; 


Figure  C-2.  The  C  Syntax  Format  of  the  Data  Packet 


The  reception  mode  of  the  PAD  function  reads  and  packetizes 
the  data.  The  PAD  accomplishes  this  task  by  reading  the 
first  14  bytes  of  data  from  the  input  stream.  These  first 
14  bytes  effectively  constitute  the  header  of  the  data 
packet.  The  header  contains  all  the  information  needed  to 
process  the  packet,  including  the  integer  in  the  num_bytes 
field  that  indicates  the  number  of  bytes  of  character  text, 
if  any,  to  follow.  If  the  input  data  stream  is  correctly 
packetized  into  a  data  structure,  then  interpretation  of  the 
packet's  fields  should  become  clearer  and  less  susceptible 
to  error. 


C-4 


The  transmission  mode  of  the  PAD  function  depacketizes  the 
data  and  sends  it  over  the  communication  channel.  The  PAD 
accomplishes  this  task  by  writing  the  packet  header  and  then 
the  text  into  a  memory  space  allocated  for  a  large  char acter 
string.  The  size  is  equal  to  4096  bytes  --  the  maximum  text 
size  —  plus  14  bytes  for  the  header  information.  If  the 
text  size  is  less  than  the  maximum,  then  only  that  much  need 
be  written.  The  RD  then  transmits  the  data  as  a  normal  byte 
stream. 

An  example  of  a  PAD  implemented  in  C  is  given  in  Figure  C-3 
(p.  C-5).  The  example  is  specific  to  UNIX/C  on  a  VAX  with 
32-bit  integers,  where  the  routines  for  converting  between 
host  (VAX)  word  order  and  network  word  order  are  mandatory. 


C-5 


#def ine  HEADER_SIZE  14  /*  WARNING:  VAX  word-ordering  */ 

#def ine  MAX_TEXT_LEN  4096 

#def ine  MAX_PACK_LEN  H£ADER_SIZE  +  MAX_TEXT_LEN 

send_packet ( packet , sock )  /*  packet  disassembler  */ 

struct  remote_pack  ‘packet; 
int  sock; 

{  register  int  i; 

char  send_buf fer (MAX_PACK  LEN ] ; 


} 


send_buf fer ( 0 ]  =  packet- >cntl_f lag; 

send_buf fer [ 1 )  =  packet->err_f lag;  /*  host-network 
conversion  */ 

* ( ( int  * ) ( send_buf f er +2 ) )  =  htonl ( packet- >code ) ; 

‘((int  *  )  ( send_buf  f  er-t-6  )  )  =  htonl  ( packet- >num_bytes  )  ; 

‘(tint  * ) ( send_buf f er +10 ) )  =  htonl ( packet- >reserved ) ; 

for(i  =  0;  i  <  packet- >num_bytes ;  i++) 

sendbuf fer ( i+14 1  =  packet->text [ 1 ] ; 

/'*  send  the  packet  */ 

return ( wr ite ( sock ,  send_buffer, 

packet- >num_bytes+HEADER_S I ZE ) ) ; 


recv_packet ( packet , sock ) 
struct  remote_pack  ‘packet; 
int  sock; 


/‘  packet  assembler 


char  recv_buf f er [ HEADER_S I ZE ]  ; 
int  result; 

/*  read  the  header  */ 

if  ((result  =  read(sock,  recv_buffer,  HEADER_SIZE ) )  != 

HEADER  SIZE) 

{ 

return  ( result ) ; 

} 

packet->cntl_f lag  =  recv_buf f er [ 0 ] ; 
packet->err_f lag  =  recv_buf fer [ 1 j ; /*  net-host 
conversion  */ 

packet->code  =  ntohl(*((int  *)  ( recv_buf fer+2 ) ) ) ; 
packet->num_bytes  =  ntohl(*((int  *)  ( recv_buf fer+6 ) ) ) ; 
packet->reserved  =  ntohl(*((int  *)  ( recv_buf fer+10 ) ) ) ; 

/*  read  the  text*/ 
if  ( packet->num_bytes ) 

{ 

if ( read ( sock ,  packet->text ,  packet- >num_bytes ) 

=packet- >num_bytes 

return (-1); 

} 

return ( 0 ) ; 


Figure  C-3.  A  Packet  Assembler/Disassembler  in  C 


